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Abstract 

The combination of two security protocols, a simple shared-key communication pro- 
tocol and the Diffie-Hellman key distribution protocol, is modeled formally and proved 
correct. The modeling is based on the I/O automaton model for distributed algorithms, 
and the proofs are based on invariant assertions, simulation relations, and compositional 
reasoning. Arguments about the cryptosystems are handled separately from arguments 
about the protocols. 



1 Introduction 

Security protocols must satisfy important correctness requirements, which means that it is 
important to be able to think about them clearly and precisely. But they can also be large 
and complicated, which makes such reasoning difficult. Ways of decomposing the reasoning 
task into clearly separable pieces are needed. This includes separating different types of 
concerns, for example, distributed algorithms issues, cryptosystem computability issues, 
probabilistic issues, and issues of accurate modeling of reality. It also includes decomposing 
the protocols using the normal techniques for decomposing distributed algorithms, based 
on levels of abstraction and parallel composition of interacting components. 

This paper describes an experiment in modeling and analyzing security protocols, using 
I/O automata [26, 23] and the usual techniques that go along with them — a combination 
of invariant assertions, simulation relations, and compositional reasoning using traces. The 
aim of the experiment is to explore how these methods can help in decomposing the task 
of reasoning about security protocols. This model and these methods have been used 
successfully for decomposing the reasoning about many standard distributed algorithms 
(see, e.g., [23, 32, 25]), and about several distributed system designs (see, e.g., [13, 14, 17, 
20]), so it is worth discovering what they can do for security protocols. 

The experiment involves combining simple shared-key communication and key distri- 
bution protocols to implement private communication. In the case we describe in detail 
here, simple Diffie-Hellman key distribution [10] is used, the protocols tolerate only passive 
eavesdroppers, and only safety properties are considered. In another case in progress, dis- 
cussed briefly here, the more complex Diffie-van Oorschot-Weiner key distribution protocol 
[11], which tolerates adversaries that can intrude more actively, is studied. Later work will 
include liveness guarantees, formulated in terms of timing properties. 

Our main guideline in studying these protocols is to try to decompose the reasoning as 
much as possible, identifying sub-problems that can be treated separately. (Although the 
examples in this paper are simple enough to be understood informally, understanding how to 
decompose them is a good first step toward understanding how to decompose more complex 
examples.) The handling of each piece should be appropriately abstract. For example, in 
discussing protocol issues, cryptosystem computability issues should be summarized by 
assumptions saying that certain values are not "easily computable" from others; number- 
theoretic arguments about why these values are not (likely to be) easily computable should 
be treated at a lower level, as mechanisms to achieve the more abstract non-computability 
guarantees. Probabilistic issues should be treated separately, as far as possible. After 
dividing up the problems in this way, we expect that the main benefit of the I/O automaton- 
based methods will be in clarifying the distributed algorithm issues. Cryptosystem issues, 
for example, may be better treated by other means, for example, the inductive techniques 
of Paulson [30] or the strand space techniques of Fabrega, et al. []. However, a general 
framework should provide a rigorous way of combining the different types of issues. 

Similarly, we try to decompose the distributed algorithms themselves as much as possi- 
ble, by: 

1. Treating sub-protocols separately, then combining them using general theorems about 
automaton composition. 



2. Giving very high level automaton specifications for services, giving separate, detailed 
descriptions of implementing algorithms, and showing, by means of simulation rela- 
tions, that the algorithms implement the services. 

3. First studying a protocol using a natural, simple cryptosystem, and later trying to 
show that its correctness properties extend to modified versions that use more elabo- 
rate cryptosystems. 

4. Combining adversaries that interact with separate protocols into a single "colluding" 
unit. 

Because I/O automata are composed by means of shared actions, and because we are 
considering only safety properties in this paper, it is natural to describe external behavior of 
automata in terms of sets of traces (i.e., sequences of external actions). The simple trace se- 
mantics yields simple and powerful projection and pasting theorems (see, e.g., [23], p. 211), 
for the behavior of compositions of automata. However, in order to enable compositional 
reasoning about particular kinds of properties, the traces must contain all the information 
relevant for those properties. For example, in treating fault-tolerance properties such as 
wait- free termination and f -failure termination compositionally, in terms of traces, it is 
convenient to include in traces special fail input actions that signal the occurrence of fail- 
ure events (see, e.g., [23, 25]). Sometimes it is convenient to consider different strengths of 
failure actions (e.g., the good, bad, and ugly failure actions in [14]). Also, in order to treat 
timing properties compositionally, it is useful to include timing information into traces. 

In the case of security protocols, some important properties involve lack of knowledge. 
To treat this compositionally, one should include something about knowledge in the traces. 
Our approach here is to give explicit learn input actions and reveal output actions by which 
a component can learn new information and reveal its knowledge, and to constrain the 
component's behavior in terms of these actions. 

Specifically, the paper contains the following. Section 2 presents a model for cryptosys- 
tems, which describe the data types encountered in the protocols, including messages, keys, 
and lower-level data from which keys are constructed. This data model also describes the 
functions that manipulate data, and the reachability (computability) relationships that say 
which values can be computed easily from which others. The data model is similar to others 
in the literature. Section 3 contains a brief review of the I/O automaton model. Section 4 
describes some "standard" types of automata that model certain components appearing in 
many systems: service environments, insecure channels, and eavesdroppers. 

Section 5 gives I/O automaton specifications for the two main security services con- 
sidered in this paper — private communication and key distribution. The specification for 
private communication is abstract: it talks only about communication and revealed informa- 
tion, and not, for example, about keys. Section 6 models and analyzes the implementation 
of private communication using an abstract key distribution service, and Section 7 treats 
the Diffie-Hellman implementation of key distribution. These protocols use particular cryp- 
tosystems, and the protocol proofs assume the limitations on easy computability expressed 
by those cryptosystems. The proofs are based on invariant assertions, and on simulation 
relations relating the protocols to the specifications for the services they are intended to 
implement. 



Section 8 shows what is involved in moving from a description of each of the two in- 
dividual protocols in terms of its own natural cryptosystem to a description in terms of a 
common, richer cryptosystem. For example, the shared-key protocol is initially analyzed 
in terms of abstract, unstructured keys taken from a simple "shared- key cryptosystem". 
However, when one combines this protocol with Dime-Hellman, it is necessary to consider 
a version that uses structured keys, taken from a richer "structured-key cryptosystem". 

Section 9 puts the pieces together, to get an implementation of private communication 
that uses shared-key communication together with Diffie-Hellman key distribution. Most 
of this is accomplished automatically from the general projection and pasting theorems for 
I/O automata. Special arguments must be made for combining the insecure channels used 
in the two protocols, and for combining the two adversaries into one. Section 10 gives a 
final discussion. 

Related work: 

The I/O automaton model is similar to the labeled transition system models underlying 
process algebras. However, notation and proof techniques typically used for I/O automata 
differ greatly from the usual process algebraic notations and methods; notably, work based 
on I/O automata uses explicit, structured representations of automaton states. 

Many researchers have stated and proved invariant assertions for security protocols (see, 
for example, [19, 36, 33, 30]). On the other hand, simulation relations have not been used 
much in prior work on reasoning about security protocols. An example of work using 
simulation relation ideas is the work on "safe simplifying transformations" by Hui and 
Lowe [18]. Also, Abadi and co-workers have used simulation relation notions in proving 
equivalences for components of secure systems (see, e.g., [1, 3]). 

Our strategy of including in traces explicit information about what can be learned and 
what can be revealed is a key to our approach to compositional reasoning about security pro- 
tocols. Including this information makes simple traces rich enough to express at least some 
interesting security properties. A similar strategy, called "negative constraints", is used by 
Cavalca and Segala in analyzing authentication protocols [8, 9]. This strategy differs from 
the "zero-knowledge" approach to proving secrecy properties (e.g., [16]) by specifying the 
particular information that can be learned and revealed, rather than assuming that noth- 
ing is learned or revealed. This extra flexibility makes it easier to compose specifications. 
Another difference between our work and work on zero-knowledge is that zero-knowledge 
proofs include probabilistic considerations, which we have so far avoided. 

Bellare and Rogaway have developed a framework for composing security protocols [6, 7]. 
Their approach is less formal than ours, but it takes probabilities into account. Lincoln, 
Mitchell, Mitchell, and Scedrov [21] present a formal approach to studying the interactions 
between protocols and cryptographic primitives, again taking probabilities into account. 
This work can be regarded as a more formal version of the work of Bellare and Rogaway. 
It is based on a form of 7r-calculus [29] and probabilistic polynomial time process models. 

Our work differs from work on formal logics for security for example, the BAN logic 
of Burrows, Abadi, and Needham [2], in that ours is carried out entirely at the level of 
automaton semantics. However, our work is compatible with work on security logics, in 
that it should be possible to express our proof methods using formal logics. Also, it should 
be possible to interpret some security logics in terms of I/O automata; the effort would be 



similar to Abadi and Tuttle's construction of an automaton semantics for a derivative of 
the BAN logic [4]. 

Our work makes extensive use of inductive proofs, mainly for verifying invariants and 
simulation relations. Paulson [30] has developed an extensive collection of methods for rea- 
soning inductively about cryptographic protocols, all supported by the Isabelle interactive 
theorem prover [31]. His approach includes some methods for proving secrecy properties, 
which involve showing that certain values are not reachable from other values within cryp- 
tosystems. We think that such methods may be useful for constructing formal proofs of 
cryptosystem unreachability results like the ones needed in this paper. Other approaches 
that should be useful in proving cryptosystem reachability results include the rank function 
approach of Schneider [33] and the strand space techniques of Fabrega et al. 

All of the related work mentioned above adopts a model where the adversary may be 
active, not just an eavesdropper. We believe that this is not a fundamental difference, in 
that our general approach can be extended to model more active adversaries. 

Sheyner and Wing [34] have formalized much of the approach of this paper using con- 
servative extensions to theories supplied with the theorem prover Isabelle. In particular, 
they have formalized shared-key cryptosystems, private communication, and essentially all 
the automata appearing in Section 6 of this paper. They have carried out interactive proofs 
using Isabelle for the fact that S\ simulates PC, for the invariants in Section 6.3, and for 
several other invariants useful in the simulation argument. They are continuing to model 
other security protocols using the same approach. 

An earlier version of the present paper appeared in the 12th IEEE Computer Security 
Foundations Workshop [24]. 1 

2 Data Model 

This section presents a basic model for the data types used in the protocols. 

2.1 Cryptosystems 

We use A to denote the empty string. 
A cryptosystem signature S consists of: 

• TNs, a set of type names. 

• FNs, a set of function names. 

• domains, a mapping from FNs to (TNs)*. 

• range s , a mapping from FNs to TNs- 

• ENs C FNs, a set of easy function names. 

A constant name is a function name / such that domains(f) = A. Let CNs Q FNs denote 
the set of constant names of C. We omit the subscript S where no confusion seems likely. 
A cryptosystem C consists of: 



1 Unfortunately, subsection numbers are messed up in that version. A corrected copy of that paper appears 
at URL http://theory.lcs.mit.edu/tds/papers/Lynch/CSFW.html. 



• A cryptosystem signature sig c . We write TNc as shorthand for TN s i 9c , etc. 

• setc, a mapping from TNc to disjoint sets. 

• fun c , a mapping from FNc to functions; We require that if domainc(f) = (ii, . . . , £&) 
and range c {f) = t then fun c (f) : setc{t\) x • • • x setc{tk) — > setc{t). 

We write sefc for Ut£TJV c setc{t). We omit the subscript C where no confusion seems likely. 
If XL){y} C se^c, we say that y is eas% reachable from X in C provided that y is obtainable 
starting from elements of X, by applying only functions denoted by function names in ENq- 

2.2 Term Cryptosystems 

If S is a cryptosystem signature, then the terms of 5, and their types, are denned recursively, 
as follows: 

1. If c 6 CN$ and range s (c) = t, then c is a term and type s (c) = t. 

2. If / G FNg, domains(f) = *i,£2j - - - , *jfe , where A; > 1, range g(f) = t, and ei, . . . , e& 
are terms of types ti,...,tk, respectively, then the expression e = f(e\, . . . , e&) is a 
term, and type s (e) = t. 

Let Terms s{t) denote the set of terms of 5 of type t. Let Terms s denote the set of all 
terms of S. 

Some of the cryptosystems we consider are best understood as term algebras derived 
from cryptosystem signatures. In these cases, the values of the various types are, formally, 
equivalence classes of terms: An equivalence relation R on Termss is said to be a congruence 
provided that the following hold. 

1. If eRe' then type s (e) = type s (e'). 

2. Suppose that / 6 FN$, domains(f) = t\,t2, ■ ■ ■ ,£&, where k > 1, range s {f) = t, 
ei, . . . , e& are terms of types t\, . . . , £&, respectively, e[, . . . , e' k are terms of types 
ii,... , ifcj respectively, and for alH, 1 < i < k, eiRe[. Then/(ei, . . . , e^)i?/(ei, . . . , e&). 

Let S be a cryptosystem signature and R a congruence on Terms s- Then the ierm cryp- 
tosystem C for 5 and R is the unique cryptosystem satisfying: 

• sig c = S. 

• If t 6 TA^c , then seic (*) is the set of all inequivalence classes of terms of type t in 
Termsc ■ 

• If / 6 -FiVc, domainc(f) = (ii, . . . ,£&) and range c (f) = t then fun c (f) is the function 
from setc{t\) x • • • x setc(tk) to setc(t) denned as follows. Suppose that e^ 6 setc{ti) 
for all «, 1 < i < k. Then /urj c (/)([ei] B , . . . , [e fc ] B ) is denned to be [/(ei, . . . , e fc )]B. 
(Since i? is a congruence, this is well-defined.) 

We use the notation Re for the congruence relation R of C. If e G Terms c, then we write 
[e]c for the equivalence class of e with respect to Re- Also, if E C Termsc then we write 
[.E]c for the set of equivalence classes [e]c for e E E. 



2.3 Cryptosystem Examples 

In this subsection we give the specific kinds of cryptosystems used later in this paper. 
These are: shared-key cryptosystems, used in shared-key communication; base-exponent 
cryptosystems, used in Dime-Hellman key distribution; and structured-key cryptosystems, 
which are essentially combination of shared-key and base-exponent cryptosystems, and are 
used when shared-key communication and Dime-Hellman key distribution protocols are 
combined. 

2.3.1 Shared-key cryptosystems 

A shared-key cryptosystem C is a term cryptosystem. The signature S = sig c is defined 
as follows. TN$ consists of two type names: "M" for messages and "if" for keys. FN$ 
consists of: 



• enc, with domain(enc) = ("M", "if") and range(enc) = "M". 

• dec, with domain(dec) = ("M", "if") and range(dec) = "M". 

• MConsts, a set of message constant names, with range(m) = "M" for all m 6 
MC onst s . 

• KConsts, a set of key constant names, with range(k) = "if" for all k 6 KConsts- 
ENs = {enc, dec}. The relation R is defined by means of all equations of the form: 

• dec(enc(m,k),k) = m, where m,k 6 Termss, type(m) = "M", type(k) = "if". 

Specifically, we define R to be the smallest congruence relation on Termss that groups 
together all terms that are related by the given equations. 

The following lemma gives some basic properties of a shared-key cryptosystem, used 
later in the proof of an invariant for a shared- key communication protocol (Lemma 6.3). 
Many properties of this sort are needed in this paper. However, we will not continue to be 
as explicit as we are here, but will revert to simply citing "properties of the cryptosystem" . 
A careful treatment of such properties is a separate effort, and would benefit from the use 
of other methods, as discussed in the Introduction. 

Lemma 2.1 Let C be a shared-key cryptosystem, S its signature and R its congruence 
relation. 

1. Suppose that e\ and e.2 are terms of type "M" with e\Re2- Let enci and deci denote 
the respective number of occurrences of enc and dec in ei, i € {1,2}. 

Then enc\ — dec\ = enci — dec^- 

2. For all m\,mi € MConsts, k 6 KConsts: 
enc(m\,k) is not R-related to mi- 

Proof: Part 1 is proved by induction on the number of substitutions required to relate 
one term to the other. Since there is only one kind of substitution, and it preserves this 
difference, the result holds. Part 2 follows from Part 1. Q 



2.3.2 Base-exponent cryptosystems 

A base-exponent cryptosystem C is a term cryptosystem in which, letting S = sig c : TN$ 
consists of two type names, U B" for bases and "X" for exponents, and FN$ consists of: 

• exp, with domain(exp) = ("-B", "X") and range(exp) = U B". 

• BConsts, a set of base constant names, with range(b) = U B" for all b G BConsts- 

• XConstl s and XConst2s, two disjoint sets of exponent constant names, with domain(x) 
A and range(x) = "X" for all x G XConstl s U XConst2s- 

ENs = {exp} U BConsts- The relation i? is denned by means of all equations of the form: 

• exp(exp(b,x),y) = exp(exp(b,y),x), wheieb,x,y G Termss, type(b) = U B", type(x) = 
type(y) = "X». 

Define B2s to be the set of all terms of the form exp(exp(b,x),y), where b G BConsts, 
x G XConstls and y G XConst2s- An augmented base-exponent cryptosystem is a base- 
exponent cryptosystem together with a distinguished element bOs of BConsts- 

2.3.3 Structured-key cryptosystems 

A structured-key cryptosystem is a combination of a shared-key cryptosystem and a base- 
exponent cryptosystem, where certain terms of the base-exponent cryptosystem are iden- 
tified with the keys. A structured-key cryptosystem C is a term cryptosystem in which, 
letting S = sig c : TNs consists of the type names "M", U B", and "X", and FNs consists 
of: 

• enc, with domain(enc) = ("M", U B") and range(enc) = "M". 

• dec, with domain(dec) = ("M", U B") and range(dec) = "M". 

• exp, with domain(exp) = ("-B", "X") and range(exp) = U B". 

• MConsts, a set of message constant names, with range(m) = "M" for all m G 

• BConsts, a set of base constant names, with range(b) = U B" for all 6 G BConst. 

• XConstls and XConst2s, two disjoint sets of exponent constant names, with range(x) = 
U X V for all rr G XConstls U XConst2 S - 

ENs = {enc, dec, exp} U BConsts- The relation i? is denned by means of all equations of 
the forms: 

• dec(enc(m,b),b) = m, where m,b G Termss, type(m) = "M", type(b) = U B" . 

• exp(exp(b,x),y) = exp(exp(b,y),x), wheieb,x,y G Termss, type(b) = U B", type(x) = 
type(y) = "X». 

Once again, we write B2c for the set of terms of the form exp(exp(b,x),y), where b G 
BConstc, x G XConstl c, and y G XConst2c- An augmented structured-key cryptosystem 
is a structured- key cryptosystem together with a distinguished element bOs of BConsts- 
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3 Input/Output Automata 

We use I/O automata as denned in [23]. Briefly, an I/O automaton A is a state machine 
having a signature consisting of a set of actions, classified as input, output, and internal 
actions. A also has a set of transitions, which are (state, action, state) triples. It is assumed 
that every input action is enabled in every state. Since we do not deal with liveness in this 
paper, the tasks defined in [23] are irrelevant. 

An execution fragment of A is an alternating (state, action, state,...) sequence, where 
successive triples correspond to transitions of A. An execution is an execution fragment 
that begins with a start state. The external behavior of A is modelled by the set of traces, 
which are the sequences of external actions arising from the executions. 

If A and B are I/O automata with the same external signature, then we say that A 
implements B provided that every trace of A is also a trace of B. Parallel composition 
of automata is defined by identifying external actions with the same name in different 
automata. We use notions of invariants and simulation relations in the usual ways; for 
definitions, see, for example [23]. 

In particular, a simulation relation from A to B is a relation F from states (A) to 
states(B) satisfying the following two properties: 

1. Each start state of A is F- related to some start state of B. 

2. For each step (sa,k,s a ) of A and each state sb of B with (sa,sb) G F, there is a 
"corresponding" execution fragment of B: it has the same trace as the given step, 
and spans from sb to some state s' B , where (s' A , s' B ) G F. 

The key fact about a simulation relation is expressed by: 

Theorem 3.1 // there is a simulation relation from A to B then A implements B. 

4 Some Generally-Useful Automata 

In this section, we give automaton models for some system components that will be used 
frequently in modeling security protocols, namely, environments for security services, inse- 
cure channels, and eavesdroppers. They are presented in a parameterized fashion so that 
they can be used in different contexts. We model these components as automata (rather 
than, for example, by using trace properties) for uniformity with the way we will model 
algorithms and system specifications, and because this makes it possible to reason about 
them assertionally. 

4.1 Environment Automata 

In this subsection we assume that U is a universal set of data values, A is a nonempty 
finite set of adversary ports (that is, locations where information can be communicated 
to an adversary), and N C U. The environment automaton Env(U,A,N) models any 
entities other than the channels from which an eavesdropper may learn information. The 
specification says that the environment is theoretically capable of communicating elements 
of U at any adversary port a E A, but in fact does not communicate any elements of N. 



Env{U,A,N) 

Signature: 

Input: 
None 



Output: 

learn(u) a , u € U, a € A 



States: 

No variables 
Transitions: 

learn (u) a 

Precondition: 

ui N 
Effect: 

none 



4.2 Insecure Channel Automata 

In this subsection we assume that U is a universal set of data values, P is a nonempty 
finite set of client ports, and A is a nonempty finite set of adversary ports. The insecure 
channel admits send and receive actions for all elements of U. It also has eavesdrop output 
actions, by which information in transit passes to an outsider. The insecure channel allows 
any message in transit to be communicated to an outsider. 



IC(U,P,A): 
Signature: 



Input: 

IC-send(u) p , q , u€U,p,q€P,p^=q 



Output: 



IC-receive(u) p , q , u € U, p,q € P, p ^ q 

eaves drop (u)p, qt a, u€U,p,q€P,p^=q, a € A 



States: 

for every p,q € P, p ^ q: 

buffer (p,q), a multiset of U, initially empty 

Transitions: 

IC-send(u)p, q 
Effect: 

add u to buffer (p,q) 

IC-receive(u)p, q 
Precondition: 

u 6 buffer (p,q) 
Effect: 

remove one copy of u from buffer (p, q) 



eavesdrop (u) p , q , a 
Precondition: 

u 6 buffer (p,q) 
Effect: 

none 



4.3 Eavesdropper Automata 

In this subsection we assume that C is a cryptosystem, P is a nonempty finite set of client 
ports, and A is a nonempty finite set of adversary ports. We define a model for an eaves- 
dropper, as a nondeterministic automaton Eve(C,P,A). Eve simply remembers everything 
it learns and hears, and can reveal anything it has, at any time. It does this by maintaining 
a variable has, initially 0. The value of has may change only in restricted ways: When 
eavesdrop (u) p ^ a or learn(u) a occurs, u gets added to has. Also, when an internal compute 
action occurs, the value resulting from applying an easy function (one in ENc) to values 
in has may be added to has. We restrict the reveal(u) output so that u 6 has, that is, 
Eve can only report a value that it "has" . Similar treatments of known information appear 
elsewhere in the literature, for example, in [12, 19, 28, 27]. 



Eve(C,P,A): 
Signature: 

Input: 



eavesdrop(u)p,q, a , u 6 setc, p,q € P, p ^ q, a 6 A 
learn(u) a , u € setc, a € A 
Output: 

reveal(u) a , u € setc, a € A 



Internal: 

compute(u, f) a , f € ENc, a € A 



States: 



has C setc, initially 



Transitions: 

eavesdrop (u) p , q , a 
Effect: 

has := has U {u} 

learn (u) a 
Effect: 

has := has U {u} 



reveal(u) a 

Precondition: 

u G has 
Effect: 
none 

compute(u, f) a 
Precondition: 

{ui, . . . ,Uk} C s.has 

u = f{ui,...,Uk) 

Effect: 

has := has U {u} 



5 The Services 

In this section, we describe the two services that are implemented by the protocols in this 
paper. They are described as automata, which is convenient for assertional reasoning. The 
use of input and output actions provides convenient ways of composing these automata with 
others, and of describing what is preserved by implementation relationships. For simplicity, 
we write these specifications to describe only safety properties, although the same methods 
can be used to handle liveness properties, formulated as time bounds (see, e.g., [22, 23]). 
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5.1 Private Communication 

This section contains a specification of the problem of achieving private communication 
among the members of a finite collection P of clients. The specification expresses three 
properties: (1) only messages that are sent are delivered, (2) messages are delivered at 
most once each, and (3) none of the messages is revealed at any "adversary port". We 
describe the problem using a high-level I/O automaton specification PC(U, P, M, A), where 
U is a universal set of data values, P is a nonempty finite set of client ports, M C [/is 
a set of messages, and A is a nonempty finite set of adversary ports. This specification 
makes no mention of distribution or keys; these aspects will appear in implementations 
of this specification, but not in the specification itself. The specification simply describes 
the desired properties, as an abstract machine. As usual for automaton specifications, the 
properties, listed separately above, are intermingled in one description. 

PC{U,P,M,A): 
Signature: 

Input: Output: 

PC-send(m)p, q , m € M, p,q € P, p ^ q PC-receive(u) p , q , u G U, p,q £ P, p ^ q 

reveal(u) a , u 6 U, a G A 



States: 



for every pair p,q € P, p^= q: 
buffer (p,q), a multiset of M 



Transitions: 




PC-send(m)p, q 


reveal(u) a 


Effect: 


Precondition 


add m to buffer (p,q) 


u $ M 




Effect: 


PC-receive(u) p , q 


none 


Precondition: 




u 6 buffer (p,q) 




Effect: 




remove one copy of u from buffer (p, q) 





Properties 1 and 2 above, which express at-most-once delivery of messages that were actually 
sent, are expressed by the transition definitions for PC-send and PC-receive. Property 3, 
secrecy, is expressed by the constraint for reveal. 

5.2 Key Distribution 

This is a drastically simplified key distribution service, which distributes a single key to 
several participants. We do not model requests for the keys, but assume that the service 
generates the key spontaneously. The service does not grant any other values, and does 
not reveal any key in K at any adversary port. The simplified key distribution service is 
specified by the automaton KD(U, P, K, A), where U is a universal set of data values, P is 
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a nonempty finite set of client ports, K C U is a set of keys, and A is a nonempty finite set 
of adversary ports. 

KD(U,P,K,A): 

Signature: 

Input: Internal: 

none choose-key 

Output: 

grant (u) p , u € U, p € P 

reveal(u) a , u € U, a G A 

States: 

chosen-key , an element of K U {J-}, initially _L 
notified C P, initially 

Transitions: 



choose-key 


reueaZ(M) a 


Precondition: 


Precondition 


chosen-key = _L 


m£ if 


Effect: 


Effect: 


chosen-key := choose k where k € K 


none 


grant (u) p 




Precondition: 




chosen-key ^ _L 




u = chosen-key 




p ^ notified 




Effect: 




notified := notified U {p} 





6 Implementing Private Communication using Shared Keys 

This section describes a straightforward shared-key communication protocol. The protocol 
simply uses a shared key, obtained from a key distribution service, to encode and decode 
messages. Throughout the section, we assume that C is a shared-key cryptosystem, P is a 
set (of clients) with at least 2 elements, and A is a nonempty finite set (of adversaries). 

6.1 The Encoder and Decoder 

We define parameterized encoder and decoder automata, parameterized by the shared-key 
cryptosystem C, the set P of clients, and elements p,q G P, p / q. The encoder encrypts 
messages from client p using the granted key, and sends the encrypted messages on the 
insecure channel from p to q. Note that, in the code for IC-send(u), we are using the 
abbreviation enc for fun c (enc) - that is, we are suppressing mention of the particular 
cryptosystem C. 

Enc(C, P) Piq , where p,q<E P, p^q : 
Signature: 
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Input: 

PC-send(m) p , q , m G [MConstc] 
grant (u) p , u € setc 



Output: 

IC-send(u)p, q , u € setc 



States: 



buffer, a multiset of elements of [MConstc], initially empty 
shared-key € [KConstc] U {-L}, initially _L 



Transitions: 

PC-send(m)p, q 
Effect: 

add m to buffer 

IC-send(u)p, q 
Precondition: 

m is in buffer 

shared-key ^ _L 

u = enc(m, shared-key) 
Effect: 

remove one copy of m from buffer 



grant (u) p 
Effect: 

if u 6 [KConstc] then 
shared-key := m 



The decoder receives messages from the insecure channel from p to q, decrypts them, and 
delivers the decrypted messages to q. 



Dec(C, P) p ,q, where p,q £ P, p / q : 

Signature: 



Input: 

IC-receive(u)p, q , u € setc 
grant(u) q , u € setc 



Output: 

PC-receive(u)p,q, u € setc 



States: 



buffer, a multiset of elements of setc{"M"), initially empty 
shared-key € [KConstc] U {-L}, initially _L 



Transitions: 

IC-receive(u)p, q 
Effect: 

if a£ setc("M") then 
add u to buffer 

PC-receive(u)p,q 
Precondition: 

m is in buffer 

shared-key ^ _L 

m = dec(m, shared-key) 
Effect: 

remove one copy of m from buffer 



grant (u) q 
Effect: 

if u g [iTConstc] then 
shared-key := m 
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PC-send 




Figure 1: Si; P = {1,2}, A = {3}; A' = {4} 

6.2 The Complete Implementation 

In the rest Section 6, we assume that U = setc, M = [MConstc], K = [KConstc], N = 
M U K, U' is a set with K C U', and A' is a nonempty finite set, disjoint from A. 

The implementation consists of encoder and decoder components, an insecure chan- 
nel, eavesdropper, and environment, plus a key distribution service. More precisely, the 
implementation, Si(C, P, A, U' , A'), is constructed by composing the following automata: 

• Enc(C, P) m , Dec(C, P) PiQ , p,q(E P,p^q. 

• IC(U,P,A), Eve{C,P,A), Env{U,A,N). 

• KD(U', P, K, A'), a key distribution service. 

and then hiding all the eavesdrop, IC-send, IC-receive, grant, and learn actions, and all the 
reveal a actions for a 6 A'. That is, we hide all but the external actions of PC(U, P, M, A), 
which are the PC-send and PC-receive actions, and the reveal a actions for a 6 A. We 
sometimes omit explicit mention of parameters of Si (and of other systems and components), 
when we think that confusion is unlikely. Figure 1 contains an interaction diagram for Si. 

Note that, in this system, the eavesdropper Eve does not acquire any information directly 
from the KD component. Later, in Section 9, we will combine this eavesdropper with 
another that arises in the key distribution service implementation. 

Our system model says that the eavesdropper learns no elements of N = M U K from 
outside sources. This choice of N is fine for this protocol, but we do not have a general 
prescription for how to choose useful sets N for all protocols. "Useful" here means that the 
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set should have a simple definition, should be large enough to include all values that the 
adversary could use to break the protocol, and should be small enough to exclude values 
produced by other protocols with which the given protocol is to be composed. The work of 
coming up with a good choice of N seems to be something of an art, similar to coming up 
with a useful invariant. 

6.3 Invariants 

In system S\, we use Enc VA , Dec VA , IC, Eve, and KD as "handles" to help in naming state 
variables in the composed state. This handle naming device for state variables is taken 
from [35]. The first invariant says that the keys granted by the key distribution service are 
consistent. 

Lemma 6.1 In all reachable states of S\, the following are true: 

1. If Enc Pj q. shared-key / _L then Enc p ^ q . shared-key = KD. chosen-key. 

2. If Decp^q. shared-key / _L then Dec p ^ q . shared-key = KD. chosen-key. 

Proof: By a simple induction on the length of an execution leading to a state. □ 

The next invariant says that all elements that appear in the insecure channel are of type 

"M" . 

Lemma 6.2 In all reachable states of Si, the following are true: 

1. If u is in IC .buffer pq then u G setc{"M"). 

The next invariant says that no element of N (= M U K; recall that M = [MConstc]) 
appears in the insecure channel. 

Lemma 6.3 In all reachable states of Si, the following are true: 

1. For all p,q G P, p ^ q, and all u G N , u ^ IC.buffer(p, q). 

Proof: By induction on the length of an execution. 

Base: The claim is true in the initial state, because the channel is initially empty. 
Inductive step: Consider a step (s,7r, s') of the implementation, where s satisfies the invari- 
ant. The interesting case is: 

1. IC-send(u) p ^ q , where u = enc(m,k) 

The precondition and type considerations imply that m G [MConstc] and A; G [KConstc]- 
So md MConstc ^ 0; let m! be any element in mfl MConstc- Similarly, knKConstc / 
0; let k' be any element in k D KConstc- Then enc(m' , k') G u. 

We claim that u ^ [MConstc]- Suppose it is and let m" be any element in uC\ MConstc- 
Then [enc(m',k')] = u = [m"]. But Lemma 2.1 implies that enc(m',k') and m" are 
not equivalent terms. It follows that u ^ [MConstc], which implies that this event 
does not add an element of M = [MConstc] to the channel IC. 

The fact that this event does not add an element of K = [KConstc] to the channel is 
easy to see, because the type of any element in any equivalence class in [KConstc] is 
U K", the type of any element in enc(m,k) is "M", and elements of one equivalence 
class all have the same type. 
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D 
As a corollary to the previous invariant, we can show that no N elements appear in Eve. has. 

Lemma 6.4 In all reachable states of S\, the following are true: 

1. If u G N then u ^ Eve. has. 

Proof: By induction. 

Base: The claim is true in the initial state, because the Eve. has is initially empty. 
Inductive step: Consider a step (s,n, s') of the implementation, where s satisfies the invari- 
ant. The interesting cases are: 

1. 7r = eavesdrop (u) p ^ a 

The fact that this preserves the claim follows from Lemma 6.3, applied to state s. 

2. 7r = learn(u) a , a G A 

The precondition (in Env(U, A, N)) says that u (fc N, so this cannot cause a violation. 

3. 7r = compute(u,f) a , a G A 

Since the claim is true in s, it must be that no element of N is in s. Eve. has. But this 
means that no equivalence class of type U K" is included in s. Eve. has (because the 
only such classes are the ones in [KConstc])- But then n cannot be enabled, because 
both easy functions, enc and dec, depend on a key class being in has. 

U 

6.4 Implementation Proof 

We show that S\ implements PC(U, P, M, A) using a simulation relation from S\ to PC(U, P, M, A). 

The relation F is denned by saying that (s,t) G F provided that the following holds: 

For each p,q G P, p / q, t.buffer(p, q) is the multiset union of three multisets, A\, Ai, A%, 

of U , where: 

1. A\ = s.EnCp^g. buffer. 

2. Ai = dec(s.IC.buffer(p,q),s.KD. chosen-key) if s. KD .chosen-key / _L else 0. 

3. A^ = dec(s. Decp^q. buffer, s.KD. chosen-key) if s. KD .chosen-key / _L else 0. 

That is, each high-level multiset of messages in transit is obtained from the messages in the 
buffers at the encoder and decoder, plus those in transit in the low-level insecure channels. 
The messages in the insecure channels and in the decoder buffer must be decoded for the 
correspondence. 

Theorem 6.5 F is a simulation relation. 

Proof: We check the two conditions required in the definition of a simulation relation: 
Start condition: This is easy, because all the relevant multisets are empty. 
Step condition: Consider (s,n,s') in the implementation, and (s,t) G F, where both s and 
t are reachable states. The interesting cases are: 
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1. 7r = IC-send(u) P: g, where u = enc(m,k) 

This maps to the trivial one-state execution fragment t of PC(U, P, M, A). We must 
argue that (s',t) 6 F. This follows because this event removes m from Enc P:q . buffer 
as it adds the encoded version u to the insecure channel, and because of the equations 
relating enc and dec. Lemma 6.1 is also used here, to ensure that the keys used for 
encoding and decoding are the same. 

2. 7T = IC-receive(u) Pt q 

The key point is that u is accepted by Dec, because it is of type "M". This following 
from Lemma 6.2. 

3. 7T = PC-receive(u) Pt q 

This corresponds to the same action in the specification automaton. In this step, 
u = dec(m, s.KD .chosen-key) for some m 6 s.Dec p ^ q . buffer (we use Lemma 6.1 here). 
Thus, by definition of the correspondence F, u 6 t.buffer(p,q), which means that n 
is enabled in the specification automaton, in state t. Let t' be the unique resulting 
state. 

To show that (s', t') 6 F, the key facts are that one copy of m is removed from 
s.DeCp^q. buffer while a copy of u is removed from the abstract channel t.buffer(p,q). 
Since u = dec(m,s.KD. chosen-key), this preserves the correspondence between the 
multisets. 



4. 7r = reveal (u. 



a 



This corresponds to reveal(u) a in the specification. We must show that u ^ M. The 
precondition for reveal(u) a (in Eve) implies that u 6 s. Eve. has. Lemma 6.4 implies 
that u £ N, which implies that u ^ M. 

D 

Theorem 6.6 S L (C, P, A, U' , A') implements PC(U,P,M,A). 

Proof: By Theorem 6.5 and Theorem 3.1. Q 

(An expanded version of) the results of this section have been checked by Sheyner and Wing- 
using the Isabelle theorem prover. 

7 Diffie-Hellman Key Distribution Protocol 

This section describes the Diffie-Hellman key distribution protocol. Throughout the section, 
we assume that C is an augmented base-exponent cryptosystem, P = {pl,p2}, and A is a 
nonempty set. 
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7.1 The Endpoint Automata 

We define two symmetric automata, for the two elements of P. The automaton for pi 
chooses an exponent x from the set XConstl , raises the distinguished base element 60 to 
the power x, and sends the result to p2. When it receives a corresponding value from p2, it 
raises that value to the power x and grants the result to the client as a key. 



DH{C,P) pl : 
Signature: 



Input: 

IC-receive{b) p2 ,pi, b 6 set c {"B") 

Output: 

IC-send(b)pi, p2 , b 6 set c ("B n ) 
grant{b) pl , b€ set c {"B") 



Internal: 

choose-exp x 



States: 



chosen-exp € [XConstl c] U {-L}, initially _L 
base-sent, a Boolean, initially false 
rcvd-base 6 set c ("B n ) U {_L}, initially _L 
granted, a Boolean, initially false 

Derived variables: 

chosen-base € setc( a B v ) U {J-}, given by: 

if chosen-exp ^ _L then exp([Wc], chosen-exp) else _L 



Transitions: 

choose-exp x 
Precondition: 

chosen-exp = _L 
Effect: 

chosen-exp := choose x 
where x 6 [XConstl c] 

IC-send(b)pi tP 2 
Precondition: 

chosen-exp ^ _L 

b = chosen-base 

base- sent = false 
Effect: 

base-sent := true 



IC-receive(b) P 2,pi 
Effect: 

rcvd-base := b 

grant (b) p i 

Precondition: 

chosen-exp ^ _L 

rcvd-base ^ _L 

b = exp(rcvd-base, chosen-exp) 

granted = false 
Effect: 

granted := true 



The automaton for p2 is the same, but interchanges uses of pi and p2, and uses XConst2 
instead of XConstl . 



DH(C,P) p2 : 
Signature: 
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Input: 

IC-receive(b)pi, P 2, 6€ setc( a B v 

Output: 

IC-send(b) p2 ,pi, b 6 set c ("B n ) 
grant (b) p2 , b€ set c ("B n ) 



Internal: 

choose-exp p2 



States: 



chosen-exp € [XConst2c] U {-L}, initially _L 
base-sent, a Boolean, initially false 
rcvd-base 6 set c ("B n ) U {_L}, initially _L 
granted, a Boolean, initially false 

Derived variables: 

chosen-base € setc( a B v ) U {J-}, given by: 

if chosen-exp ^ _L then exp([bOc], chosen-exp) else _L 



Transitions: 

choose-exp p2 
Precondition: 

chosen-exp = _L 
Effect: 

chosen-exp := choose x 
where x 6 [XConst2c] 

IC-send(b) P 2,pi 
Precondition: 

chosen-exp ^ _L 

b = chosen-base 

base- sent = false 
Effect: 

base-sent := true 



IC-receive(b)pi, P 2 
Effect: 

rcvd-base := b 

grant (b) P 2 

Precondition: 

chosen-exp ^ _L 

rcvd-base ^ _L 

b = exp (rcvd-base, chosen-exp) 

granted = false 
Effect: 

granted := true 



7.2 The Complete Implementation 

In the rest of Section 7, we assume that U = setc, K = [B2c] (the set of doubly- 
exponentiated bases), X = [XConstlc] U [XConst2c], and N = K U X. 

The implementation consists of two endpoint automata, an insecure channel, an eaves- 
dropper and an environment. Specifically, implementation S2(C,P,A) is constructed by 
composing the following automata: 

• DH(C,P) P , p 6 P, endpoint automata. 

• IC{U,P,A), Eve{C,P,A), Env(U,A,N). 

and then hiding all the eavesdrop, IC-send, IC-receive, and learn actions. That is, we 
hide all but the external actions of KD(U, P, K, A), which are the grant and reveal actions. 
Figure 2 contains an interaction diagram for S2. 
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Figure 2: S 2 ; P ={1,2}; A ={4} 



7.3 Invariants 



In system 5*2, we use DH(p) for p E P, /C, and Ewe as handles to help in naming state 
variables in the composed state. The first invariant says that messages that have been 
received or are in transit are correct. 

Lemma 7.1 In all reachable states of S2, the following are true: 

1. If DH (jj). rcvd-base 7^ _L andq 7^ p then DH(q). chosen- exp 7^ JL, and DH(q).rcvd-base = 
DH(p). chosen-base. 

2. If u E IC . buffer (p,q), then DH(p). chosen- exp 7^ _L, and n = DH(p). chosen-base. 

The next invariant says that no iV elements ever appear in Eve. has or in the insecure 
channel. 

Lemma 7.2 In all reachable states of S2, the following are true: 

1. For all p,q E P, p 7^ g, and a// u E N, u ^ IC .buffer (p,q). 

2. If u E N then u £ Eve.has. 

Proof: Analogous to the proof of Lemma 6.4. □ 
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7.4 Implementation Proof 

We show that S2 implements KD(U, P, K, A) using a simulation relation. The relation F is 
defined by saying that (s,t) 6 F provided that: 

1. t. chosen-key = exp(s. DH(pl). chosen-base, s.DH(p2). chosen-exp) if s.DH (pi) .chosen-exp / 
_L and s.DH (p2) .chosen-exp / _L; t. chosen-key = _L otherwise. 

2. t. notified = {p G P : s.DH (p). granted}. 

Condition 1 says that the chosen key in KD is obtained by doubly-exponentiating 60 with 
both the chosen exponents in the Diffie-Hellman protocol. If it is not the case that both 
exponents have been chosen, then the chosen key is undefined. 

Theorem 7.3 F is a simulation relation. 

Proof: Start condition: Easy. 

Step condition: Consider (s, n, s') and t as usual, and consider cases. The most interesting 

cases are: 

1. 7r = choose-exp p . 

If s.DH (q). chosen-exp = _L, where q / p then this maps to the trivial one-state 

execution fragment t. The correspondence is trivially preserved (Part 1 is vacuous). 

Otherwise, this corresponds to choose-key, with a chosen value of 

exp(s' .DH (pi). chosen-base, s'.DH(p2). chosen-exp). 

Enabling is straightforward, as is the preservation of the simulation relation. 

2. 7r = grant (b) p 

This corresponds to grant (b) p in the specification. The interesting fact to show here 
is the enabling condition, in particular, that b = t. chosen-key. The precondition of n 
in the implementation implies that b = exp(s.DH(p).rcvd-base,s.DH(p). chosen-exp). 
But Lemma 7.1 implies that b = exp(s.DH(q). chosen-base, s.DH(p). chosen-exp), 
and properties of the cryptosystem imply that this is equal to 

exp(exp([bO],s.DH(pl). chosen-exp), s.DH(p2). chosen-exp). Then the definition of F 
says that this is equal to t. chosen-key, as needed. 

3. 7T = reveal(u) a 

This corresponds to reveal(u) a in the specification. We must show that u ^ K. The 
precondition for reveal(u) a (in Eve) implies that u G s. Eve. has. Lemma 7.2 implies 
that u ^ N, which implies that u ^ K, as needed. 
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Theorem 7.4 S 2 (C,P,A) implements KD(U,P,K,A). 
Proof: By Theorems 7.3 and 3.1. 
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8 Algorithms Using Structured-Key Cryptosystems 

In this section, we modify the implementations of private communication and of key dis- 
tribution, S\ and 52, so that they use a common structured- key cryptosystem, rather than 
separate shared-key and base-exponent cryptosystems. We show that the resulting systems 
are still correct. The proofs use simulation relations to the original systems. 

Throughout this section, and for the rest of the paper, we fix C to be any augmented 
structured-key cryptosystem. 

8.1 Private Communication 

We show that moving from a shared-key cryptosystem to a structured-key cryptosystem 
does not disturb the correctness of the simple shared-key communication protocol. The 
key idea is that the new mechanisms added to the cryptosystem do not contribute any new 
ways of computing messages of the original shared-key cryptosystem. 

8.1.1 Notation and assumptions 

Starting from the fixed augmented structured- key cryptosystem C, we derive a shared-key 
cryptosystem C, by denning MConstc = MConstc and KConstc = B2c- That is, we use 
the B2 terms in C as "names" for keys in C . 

In this subsection we assume that P is a set with at least 2 elements, A is a nonempty 
finite set, U = set c , M = [MConstc], K = [B2 C ], and X = [XConstl c ] U [XConst2 c ]- 

We also define W to be the set of all elements w 6 setc{ u M") that can be obtained as 
follows. In cryptosystem C, w is obtained from an element m 6 setc{ u M n ) by applying 
some number (possibly 0) of enc operations with second arguments in setc{ u B") — K. 
Informally speaking, w is obtained by "wrapping" some message of the derived shared-key 
cryptosystem in a series of encryptions based on keys not in B2. Finally, we assume that 
N = W U K U X , U' = U = setc, and A' is a nonempty finite set, disjoint from A. 

The set W is used to describe the elements of type "M" that the eavesdropper is not 
allowed to learn. We have chosen this particular set W because it has a simple definition, 
because it includes all elements of type "M" that could help the eavesdropper to compute 
elements that are supposed to remain unknown (the MConsts), and because it excludes 
values produced by other protocols with which the given protocol is to be composed. Other 
choices of W besides ours are possible. 

8.1.2 New implementation 

The formal definitions of Enc3 and DecS are nearly identical to those of Enc and Dec. The 
difference is that the new automata use elements of type U B" in place of KConsts. Also, 
the parameters have new meanings, as denned just above. 

Enc3(C, P)p, q where p,q 6 P, p / q : 

Signature: 
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Input: 

PC-send(m) p , q , m G [MConstc] 
grant (u) p , u € setc 



Output: 

IC-send(u)p, q , m € setc 



States: 



buffer, a multiset of elements of [MConstc], initially empty 
shared-key 6 set c ("B n ) U {_!_}, initially _L 



Transitions: 

PC-send(m)p, q 
Effect: 

add m to 



IC-send(u)p, q 
Precondition: 

m is in buffer 

shared-key ^ _L 

u = enc(m, shared-key) 
Effect: 

remove one copy of m from buffer 



grant (u) p 
Effect: 

if BE set c ("B v ) then 
shared-key := u 



Dec(C, P) p , q , where p,q<E P, p^q : 
Signature: 



Input: 



Output: 



IC-receive(u)p, q , u € setc 
grant(u) q , u € setc 



PC-receive(u)p,q, u € setc 



States: 

buffer, a multiset of elements of setc{"M") 
shared-key 6 set c ("B n ) U {_L}, initially _L 

Transitions: 

IC-receive(u)p, q 
Effect: 

if a£ set c ("M v ) then 
add u to buffer 



grant (u) q 
Effect: 

if u e set c ("B n ) then 
shared-key := m 



PC-receive(u)p,q 
Precondition: 

m is in buffer 

shared-key ^ _L 

m = dec(m, shared-key) 
Effect: 

remove one copy of m from buffer 



We define 53 to be the system from Section 6, but implemented using the structured- 
key cryptosystem C rather than a shared-key cryptosystem. That is, Ss(C,P,A,U',A') is 
constructed by composing: 
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• Enc3 (C, P) M and Dec3 (C, P) M , p,qeP,p^q. 

• 7C(£/,P,A), Eue(C,P,A), £««(*/, A, JV). 

• KD(U',P,K,A'). 

and then hiding all the eavesdrop, IC-send, IC-receive, grant, and learn actions, and the 
reveal a actions for a G .A'. That is, we hide all actions except the external actions of 
PC(U,P,M,A), which are the PC-send and PC-receive actions and the reveal a actions for 
a 6 A. We want to show that S 3 (C, P, A, U' , A') implements PC(U, P, M, A). 

8.1.3 Invariants 

Lemma 8.1 In all reachable states of S3, the following are true: 

1. For all p, EncS P:Q . shared-key G K U {-L}. 

2. For allp, Dec3 p , q . shared-key G K U {_L}. 

Proof: By induction; the only interesting case is grant, but this is straightforward from the 
precondition of grant in KD. □ 

Lemma 8.2 In all reachable states of S3, the following are true: 

1. For allp,q, if u G IC '.buffer (p,q) then u = enc(m,k), where m G M and k G K. 

2. For all p,q, all x G X, x ^ IC. buffer (p,q). 

Proof: Part 1 is proved by induction, using Lemma 8.1. The interesting case is IC-sendp^; 
this follows because the precondition (in Enc^) implies that the message sent is of the 
indicated form. Part 2 follows from Part 1. □ 

Lemma 8.3 In all reachable states of S3, the following are true: 

1. No element of X is in Eve. has. 
Proof: By induction. The interesting cases are: 

1. eavesdrop (u) p ^ a 

Lemma 8.2 implies that u = enc(m, k) for some m G M and k G K. This is not in X, 
which shows that the invariant is preserved. 

2. learn(u) a 

The precondition (in Env) implies that u (fc X, so this cannot cause a violation of the 
claim. 

3. compute (u, f) a 

Since no element of X can be computed in cryptosystem C, the claim is preserved. 

D 
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The following lemma, Lemma 8.4, has a different style from the other invariants we have 
stated so far. It does not say that no element of W may appear in has. Rather, it says 
that if such an element, w, appears in has, then any element m of setc( u M n ) that is easily 
reachable from w, for example, the "unwrapped" element of setc( u M") from which w is 
constructed, must also be in has. 

Also note that we do not give any invariants here saying that K or M elements do not 
appear in Eve. has, as we did in Section 6.3. This is because (in the spirit of modularity) 
we prefer to avoid re-proving facts for S3 that have already been proved for S\. 

Lemma 8.4 In all reachable states of S3, the following are true: 

1. Assume that (M U K) n Eve. has = 0. If w € W f) Eve.has and m G set c >{"M") is 
easily reachable from {w} U (setc( "B") — K) in C, then m G Eve.has. 

Proof: By induction. Fix (s, n, s') as usual. The interesting cases are: 

1. eavesdrop {u) p ^ a 

Note that the form of u, as described in Lemma 8.2, implies that u G W. The 
interesting situation is where w, the element in the statement of the invariant, is 
equal to u, the element newly inserted into has. So suppose that m G setc is easily 
reachable from {u} U (setc{ u B v ) — K) in C. Then properties of the cryptosystems C 
and C imply that m = u. But u is explicitly put into Eve.has by this step, as needed. 

2. learn(u) a 

The precondition (in Env) implies that u ^ W , so this cannot cause a violation of the 
claim. 

3. compute (u, f) a 

The interesting case is where the new element u being computed is in W, so assume 
that u G W. Suppose that (M U K) n s' .Eve.has = and that m G setc ls easily 
reachable from {u} U {set c { u B") - K) in C. It follows that (M U K) n s. Eve.has = 0. 

If the function / is exp, then some element of X must be in s. Eve.has. But Lemma 
8.3 implies that there is no such element. So / must be either enc or dec. Since no 
element of K is in s. Eve. has, the second argument in the application of / must be in 
setc( u B") — K. The first argument is some u' G s. Eve. has. It follows that m is easily 
reachable from {u'} U (setc( u B n ) — K) in C. Also, since u G W, properties of the 
cryptosystem C imply that also u' G W. But then the inductive hypothesis implies 
that m G s. Eve. has. Therefore, m G s'. Eve. has, as needed. 

D 

8.1.4 Implementation proof 

We prove the correctness of S3 as a consequence of that of S\{C , P, A, U' , A'). By our 
previous result about Si, Theorem 6.6: 

Lemma 8.5 Si(C , P, A, U' , A') implements PC {setc, P,M, A). 
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In order to prove correctness of S 3 (C, P, A, U' , A'), we would like to demonstrate a 
simulation relationship from S 3 {C,P,A,U',A') to Si{C',P,A,U',A'). To do this, we first 
make the interfaces consistent, by denning S' 3 (C, P, A, U' , A') from S 3 by hiding the actions 
reveal(u) a , u G U — seta, o, G A. 

Lemma 8.6 If (3 is a trace of S 3 (C,P,A,U' ,A') then (3 with all reveal (u) actions removed, 
u<EU - seta, is a trace of S' 3 {C, P, A, U' , A'). 

Now we define the relation F from S' 3 (C,P,A,U',A') to Si{C ,P,A,U' ,A'): {s,t) G F 
provided: 

1. For all components except Eve, the states are identical in s and t. 

2. s.Eve. has n seta Q t. Eve. has. 

Theorem 8.7 F is a simulation relation. 

Proof: Start condition: Easy. 

Step condition: Consider (s,7r, s') and t as usual. 

We claim first that no element u E MUK appears in s.Eve. has. For, if such an element 
did appear in s.Eve. has, the fact that (s,t) G F would imply that u G t. Eve. has. But this 
would contradict Lemma 6.4, an invariant for S\. 

The most interesting cases are: 

1. 7r = reveal(u) a , a E A 

We consider two subcases: 

(a) u G seta 

Then the corresponding fragment consists of a single step, with the same action. 
The precondition of n in S' 3 implies that u G s.Eve. has. Since (s, t) G F, we have 
also that u G t. Eve. has. Therefore, n is enabled in t. Since reveal actions have 
no effect on the state, the relation F is preserved. 

(b) u G U — seta 

Then the corresponding fragment consists of the single state t. Since n is an 
internal action of S' 3 , the external behavior corresponds as needed. 

2. 7r = compute (u, f) 

(a) m G se^c' 

Then since / G ENc, f must be exp, enc, dec, or an element of B Const. We 
consider cases: 

i. / = enc or / = dec, with the second argument in K. 

Then the precondition implies that this K element, say k, must be in 
s.Eve. has. But this contradicts a claim at the beginning of the proof, which 
means that this case cannot occur. 
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ii. / = enc, with the second argument in setc( u B") — K 

Then properties of the cryptosystem C imply that / yields a result u E 
(U — setc), contradicting the requirements of this case. 

iii. / = dec, with the second argument in setc( u B") — K 

Then the corresponding fragment consists of the single state t. We must show 
that the correspondence is preserved. By properties of the cryptosystem C, 
the first argument of / must be some element w E W. By the precondition 
of 7r, w E s.Eve. has. Then Lemma 8.4, together with the fact that (M U 
K) fl s.Eve. has = 0, implies that u E s.Eve. has, that is, u is already in the 
has set, before the current step. Therefore, since (s, t) E F, we have also 
u E t. Eve. has. It follows that (s',t) E F, that is, the correspondence is 
preserved. 

iv. / = exp 

Then / must be applied with a second argument x E X, and x E s.Eve. has. 
But this violates an invariant for S' 3 , Lemma 8.3, which means that this case 
cannot occur. 

v. / E B Const c 

This yields a result u E (U — setc), contradicting the requirements of this 
case. 

(b) u E U — setc 

Then the corresponding fragment consists of the single state t. Since u £ setc, 
the correspondence is preserved. 



3. 7r = learn (u 



a 



(a) u E setc 

Then the corresponding fragment consists of a single step, with the same action. 
To see that this is enabled, note that u ^ N, by the precondition in S3. In 
particular, u ^ M U K. This implies that learn(u) is enabled in S\. Since the 
same element is added to both has sets, the correspondence is preserved. 

(b) u eU - setc 

Then the corresponding fragment consists of the single state t. Since u £ setc, 
it is easy to see that the correspondence is preserved. 

4. 7T = eavesdrop (u) p ^ a 

The precondition of n in S' 3 implies that u E s.IC .buffer pq . Since (s,t) E F, we have 
that also u E t.IC .buffer pq . Therefore, n is enabled in t. Since the same element is 
added to both has sets, the correspondence is preserved. 

D 

Theorem 8.8 S' 3 (C,P,A,U',A') implements Si{C ,P,A,U' ,A'). 

Proof: By Theorems 8.7 and 3.1. Q 
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Lemma 8.9 If (3 is a trace of Ss{C , P, A, U' , A') then (3 with all reveal (u) actions removed, 
for ueU - seta, is a trace of Si(C, P, A, U' , A 1 ). 

Proof: By Theorem 8.8 and Lemma 8.6. Q 

Theorem 8.10 S 3 (C, P, A, U' , A') implements PC {U,P,M, A). 

Proof: Let (3 be a trace of S${C, P, A, U', A'). Then Lemma 8.9 implies that (3\ is a trace 
of S\(C , P, A, U',A'), where (3\ is equal to (3 with all reveal(u) actions removed, for u 6 
U — seta ■ Then Lemma 8.5 implies that (3\ is a trace of PC {seta, P, M, A). It follows that 
(3\ is a trace of PC{setc,P,M,A). Now, since (3 differs from (3\ only by including some 
reveal actions for elements in U — seta, it follows that (3 is a trace of PC{setc, P, M, A). 
D 

The proofs of the results in this and the next subsection deal with specific cryptosystems. 
It would be interesting to extract general theorems that could be applied to get such results. 
Such theorems would involve some kind of notion of "embedding" of one cryptosystem in 
another, and statements articulating when a protocol that works with a cryptosystem also 
works with any cryptosystem in which that cryptosystem is embedded. 

8.2 Key Distribution 

It is not hard to see that moving from a base-exponent cryptosystem to a structured-key 
cryptosystem does not disturb the correctness of the Difne-Hellman protocol. The key idea 
is that the new mechanisms added to the cryptosystem involve the new message type "M" , 
and do not contribute any new ways of computing bases or exponents. 

We proceed formally as in the previous subsection. Starting from the fixed augmented 
structured- key cryptosystem C, we derive an augmented base-exponent cryptosystem C 
by defining BConsta = BConstc, XConstla = XConstlc, XConst2a = XConst2c, and 
Wa = bOc- In this subsection we assume that P = {pl,p2}, A is a nonempty finite set, 
U = set c , K = [B2 C ], X = [XConstlc] U [XConst2 c ], and N = K U X. 

The new endpoint automata are syntactically the same as the old endpoint automata. 
The only difference is that the subscript C now refers to a structured-key cryptosystem. 
We define 64 to be the system from Section 7, but implemented using the structured- 
key cryptosystem C rather than a base-exponent cryptosystem. That is, S±{C,P,A) is 
constructed by composing: 

. DH{C,P) p ,pEP. 

• IC{U,P,A), Eve{C,P,A), Env{U,A,N). 

and then hiding the eavesdrop, IC-send, IC-receive, and learn actions. That is, we hide 
all actions except the external actions of KD{U,P,K,A), which are the grant and reveal 
actions. We want to show that Si{C,P, A) implements KD(U,P,K,A). We show this as a 
consequence of the correctness of S2{C',P,A). By our previous result about 52, Theorem 

7.4: 

Lemma 8.11 S 2 {C',P,A) implements KB {set a,P,K, A). 
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In order to prove correctness of Si(C, P, A), we would like to demonstrate a simulation 
relationship from S 4 {C,P,A) to S 2 {C',P,A). We define S' 4 {C,P,A) from S A by hiding the 
actions reveal (u) a , u E U — setc, a E A. 

Lemma 8.12 If (3 is a trace of S±(C,P,A) then (3 with all reveal(u) actions removed, for 
u E U — setc, i> s a trace of S' 4 (C, P, A). 

Now we define the relation F from S' 4 (C, P, A) to ^(C, P, A): (s, t) E F provided: 

1. For all components except Eve, the states are identical in s and t. 

2. s.Eve. has n setc Q t. Eve. has. 

Theorem 8.13 F is a simulation relation. 

Proof: Analogous to that of Theorem 8.7. 

Start condition: Easy. 

Step condition: Consider (s,7r, s') and t as usual. The most interesting cases are: 

1. 7r = reveal (u) a 

Analogous to the reveal case in the proof of Theorem 8.7. 

2. 7r = compute(u, f) 

(a) u E setc 

Then properties of the structured-key cryptosystem imply that / must be either 
exp or an element of BConst. Moreover, any arguments required by / are also in 
setc- Since such arguments must be in s.Eve. has (by the enabling condition), 
the definition of F implies that they are also in t. Eve. has. It follows that n is 
enabled in t. 

Thus, we may allow the corresponding fragment to consist of a single step, with 
the same action. Since the same element is added to both has sets, the corre- 
spondence is preserved. 

(b) u E U — setc 

Analogous to the corresponding case for the compute action in the proof of 
Theorem 8.7. 



3. 7T = learniu 



a 



(a) u E setc 

Then the corresponding fragment consists of a single step, with the same action. 
To see that this is enabled, note that u ^ N = K UX, by the precondition in S'^. 
This implies that learn(u) is enabled in S2. Since the same element is added to 
both has sets, the correspondence is preserved. 

(b) u E U — setc 

Then the corresponding fragment consists of the single state t. Since u ^ setc-, 
it is easy to see that the correspondence is preserved. 
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4. 7r = eavesdrop(u) P: q : a 

Analogous to the eavesdrop case in the proof of Theorem 8.7. 



Theorem 8.14 S' 4 (C,P,A) implements S 2 {C , P, A) . 

Proof: By Theorems 8.13 and 3.1. D 

Lemma 8.15 If (3 is a trace of S±(C,P,A) then (3 with all reveal(u) actions removed, for 
u 6 U — setc is a trace of S 2 (C, P, A). 

Proof: By Theorem 8.14 and Lemma 8.12. □ 

Theorem 8.16 S 4 {C,P,A) implements KD(U,P,K, A). 

Proof: Let (3 be a trace of S±(C,P,A). Then Lemma 8.15 implies that (3\ is a trace of 
S 2 (C',P,A), where (3\ is equal to (3 with all reveal(u) actions removed, for u 6 U — setc- 
Then Lemma 8.11 implies that (3\ is a trace of KD(setc,P,K,A). It follows that (3\ is 
a trace of KD(setc,P,K,A). Now, since (3 differs from (3\ only by including some reveal 
actions for elements in U — setc it follows that (3 is a trace of KB {setc, P, K, A). □ 



9 Putting the Pieces Together 

Now we describe how to put the previous results together, to get an implementation of 
private communication that uses the shared-key communication protocol in combination 
with the Dime-Hellman key distribution service. The first step combines the two protocols 
using ordinary composition, but still keeps the insecure channels, eavesdroppers, and envi- 
ronments for the two algorithms separate. The second step combine the two channels into 
one and likewise for the eavesdroppers and the environments. 

9.1 Composing Diffie-Hellman and Shared-Key Communication to get 
Private Communication 

Recall that we have already fixed C to be an augmented structured-key cryptosystem. We 
now assume, for the rest of the paper, that U = setc, P = {pl 5 p2}, P' = {pl',p2'}, A 
is a nonempty finite set, M = [MConst c ], K = [B2 C ], X = [XConstl c ] U [XConst2 c ], W 
is the set of elements of setc( u M") that can be obtained from elements of setc{ u M v ) U 
(setc( u B") — K) in C using enc, N = W U K U X, and A' is a nonempty finite set, disjoint 
from A. 

The combined system S5 is constructed by composing: 

. Enc3(C, P) Ptq , Dec3(C, P) M , p,qeP,p^q. 

• DH5 P , p 6 P; each of these is a renamed version of DH(C, P) p , with the subscripts in 
IC-send Pyq and IG -receive q ^ p actions renamed to their primed versions. 
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Figure 3: S 5 

• IC(U,P,A), Eve{C,P,A), Env(U,A,N). 

• IC{U,P',A'), Eve(C,P',A'), Env(U,A',N'). 

and hiding all actions except for the external actions of PC(U,P,M, A), which are the 
PC-send, PC-receive, and reveal a actions for a G A. Figure 3 contains an interaction 
diagram for S$. 

Theorem 9.1 S 5 implements PC(U,P,M,A). 

Proof: This follows from Theorems 8.16 and 8.10, using general projection and pasting 
lemmas for I/O automata. Let a be an execution of Sg. We produce an execution a' of 
PC(U,P,M,A) such that trace(a') = trace(a). 

Define Ti = Enc3 p \ tp2 x Dec3 p \ ip2 x Enc3 p2 , p i x Dec3 p2 , p i x IC(U, P, A) x Eve(C, P, A) x 
Env(U,A,N) and T 2 = DH5 pl x £>#5 p2 x Ic{u,P',A') x Eve(C,P',A') x En«(£/, A',iV'). 
Define a\ = a\T\ and a 2 = a\T 2 . By I/O automaton projection lemmas, a\ and a 2 are 
executions of Ti and T 2 , respectively. (See [23], Chapter 8.) 

Let T3 be the same as T 2 but with all actions except for the grant actions and reveal 
actions hidden; a 2 is also an execution of T3. Then T3 is exactly the same as Si(C,P,A') 
except for renaming of elements of P, everywhere except in grant actions, to corresponding 
elements of P' . By Theorem 8.16, S A (C,P,A') implements KD(U,P,K,A'). Since all the 
renaming happens internally, this implies that T3 implements KD(U,P,K,A'). 

It follows that there exists an execution 013 of KD(U, P, K, A') that agrees with a 2 , and 
so also with a, on the external actions of KD(U, P, K, A'), that is, on the grant(u) p actions, 
u € U , p 6 P and reveal(u) a actions, u 6 U , a 6 A'. 
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Now I/O automaton pasting lemmas (see [23]) yield an execution a^ oiT\xKD(U, P, K, A') 
such that ai\T\ = a\ and ai\KD(U, P, K, A') = 03. Thus, 04 agrees with a on T\ and on 
the external actions of KD(U, P, K, A'). 

Now define T 4 = 7\ x KD(U,P,K,A'), with all except the PC-send, PC-receive and 
reveal(a), a <E A actions hidden. Note that T 4 = S 3 (C, P, A, U, A'). Now Theorem 8.10 
implies that Ss(C, P, A, U, A') implements PC(U,P,M,A); therefore, there is an execution 
a' of PC(U, P, M, A) that agrees with 04 on all external actions of PC(U, P, M, A). Hence, 
a' agrees with a on all external actions of PC(U, P, M, A). This is as needed. Q 

9.2 Merging Channels, Adversaries, and Environments 

The final implementation, Se, is obtained from S5 by merging the two separate insecure 
channels into one, and likewise for the two adversaries and the two environments. To do 
this, and yet keep the same interfaces, we extend the definitions of IC and Eve to allow 
two types of ports, primed and unprimed. S% consists of: 

. Enc3(C, P) Ptq , Dec3(C, P) p , q , p,qeP,p^q. 

• DH5 P , p<EP. 

• IC{U,P,A,P',A'), Eve{C,P,A,P',A'). 

• Env{U,AuA',NUN'). 

Here, the extended IC is the same as IC(U,P U P',A U A') but only has actions with 
subscripts p,q,a where either p, q E P, a 6 A or p, q E P', a E A'. Similarly for the 
extended Eve. Also, Se hides all actions except for the PC-send, PC-receive, and reveal a 
actions for a E A, that is, the external actions of PC(U, P, M, A). 

The combined eavesdropper eavesdrops and learns on all adversary ports in AuA', and 
can use all this information in calculating its has information, which resides in a single state 
component. The combined environment avoids communicating any information in N U N'. 
We claim that Se implements 5s, which implies that Se implements PC(U,P,M,A). To 
prove this result, we define S7, which is just like S5 except that it combines the eavesdroppers 
(but not the channels or environments). We define a simulation relation F from S7 to 5s, 
where (s,t) E F exactly if: 

1. For all except the Eve components, the states are identical in s and t. 

2. s.has Ct.Eve(C,P,A).has. 

3. s.has Ct.Eve(C,P',A').has. 

This relation says, essentially, that any information that the combined eavesdropper can 
acquire, in the context of the given protocols, is something that each of the individual 
eavesdroppers could acquire anyway. 

Theorem 9.2 F is a simulation relation. 
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Proof: The initial condition is immediate, because s.has is empty. For the step condi- 
tion, the interesting cases are as follows. Let b and b' be arbitrary elements of A and A', 
respectively. 

1. reveal(u) a , a G A 

We know that u G s.has. So by definition of F, we have that u G t.Eve(C, P, A). has. 
Let this step correspond to a single step, with the same reveal(u) a action. Since 
u G t.Eve(C,P,A).has, this action is enabled in 5s. 

2. reveal(u) a , a E A' 
Analogous to the previous case. 

3. learn(u) a , a G A U A' 

The execution fragment corresponding to this step consists of two steps, with actions 
learn(u)b, learn(u)y ■ By the precondition, «£[/- (TV U N'). So u G (U — N) and 
u G (U — N'). It follows that the two learn actions are enabled in 55. Since the same 
element u is added to all three has sets, the correspondence is preserved. 

4. compute(u, f) a , a G A U A' 

The execution fragment corresponding to this step consists of two steps, with ac- 
tions compute(u, /)j, compute(u, f)y . The precondition implies that all the arguments 
needed for this computation of / are in s.has. Since (s,t) G F, these areguments are 
also in t.Eve(C, P, A). has and in t.Eve(C, P', A'). has. It follows that the two compute 
actions are enabled in 5s. Since the same element u is added to all three has sets, the 
correspondence is preserved. 

5. eavesdrop (u) a , a E A 

Then Lemma 8.2 implies that u is of the form enc(m,k), m G M, k G K. There- 
fore, u G U — N'. The corresponding fragment consists of two steps, with actions 
eavesdrop (u) a , learn (u) y. The eavesdrop action is enabled in S5 because the chan- 
nel states are identical in states s and t. The learn action is enabled in S7 because 
u G U — N' . Again, since the same element u is added to all three has sets, the 
correspondence is preserved. 

6. eavesdrop (u) a , a G A' 

Then u is of the form exp(bO,x) G U — N. The corresponding fragment consists of two 
steps, with actions eavesdrop (u)' a , learn(u)b- The eavesdrop action is enabled in 5s 
because the channel states are identical in states s and t. The learn action is enabled 
in S7 because u G U — N. Since the same element u is added to all three has sets, the 
correspondence is preserved. 



D 



Theorem 9.3 S-j implements S5. 
Proof: By Theorems 9.2 and 3.1. 
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The essence of Theorems 9.2 and 9.3 is a relationship between Eve(C, P, A, P' , A') and 
the composition Eve(C, P, A) x Eve(C, P', A'). The reason that this relationship is described 
in terms of the complete systems SV and S5 (rather than just the eavesdroppers) is that the 
relationship depends on assumptions about the contexts in which the eavesdroppers run. 
The key facts used about the contexts appear in the arguments for the eavesdrop cases in 
the proof of Theorem 9.2. Basically, these facts say that any message that can appear in 
the insecure channel of either protocol could also be generated by the environment in the 
other protocol. It is possible to extract a general combining theorem for eavesdroppers, 
using abstract models of the environments and protocols that express just this type of 
noninterference. Since this involves some notational complexities, we leave this for future 
work. 

Lemma 9.4 Se implements S7. 

The fact that Se implements SV is easy, based on the following two lemmas: 
Lemma 9.5 Env(U, A U A', N U N') implements Env(U, A, N) x Env(U, A', N'). 
Lemma 9.6 IC{U, P, A, P', A') implements IC{U,P,A) x IC{U,P',A'). 

This all yields: 
Lemma 9.7 Se implements S5. 
Proof: By Lemma 9.4 and Theorem 9.3. Q 

Theorem 9.8 S 6 implements PC(U,P,M,A). 

Proof: By Lemmas 9.7 and Theorem 9.1. Q 

10 Discussion 

In this paper, we have modeled and analyzed the combination of simple shared-key commu- 
nication with Difhe-Hellman key distribution, in the presence of an eavesdropper adversary. 
Even though this example is very simple, we have studied it using many kinds of decompo- 
sition, including: 

1. Separating distributed algorithms issues from other issues, like cryptosystem reacha- 
bility issues. 

2. Treating the two sub-protocols separately, then combining them using general theo- 
rems about automaton composition. 

3. Giving high level service specifications, giving detailed descriptions of implementing 
algorithms, and using simulation relations to show that the algorithms implement the 

services. 
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4. First studying the protocols using simple cryptosystems and later extending them to 
use more elaborate cryptosystems. 

5. Combining separate adversaries into one. 

We believe that understanding these decomposition methods in a simple context is an 
important first step toward extending them to more complicated protocols. 

It appears possible to decompose the presentation in this paper even more. For example, 
one might define a notion of embeddings of cryptosystems and obtain the results of Section 
8 as consequences of general theorems about such embeddings. Or, one might formulate 
and prove a general combining theorem for eavesdroppers and use it in the proof of Lemma 
9.4. 

In work in progress, we are extending these ideas to more complex protocols like that 
of Dime, van Oorschot, and Weiner [11], which tolerate more active adversaries. So far, it 
appears that the modeling/analysis ideas of this paper scale well to the more complicated 
examples. Some issues that arise in modeling the protocol of [11] are: The cryptosystems 
are more complicated, so more complicated arguments must be made about reachability; 
for example, the analogues of the set W defined in Section 8.1.1 become more complicated. 
Also, because the adversary has more active control of the communication system, it is 
appropriate to combine the adversary and communication system into a single automaton 
model. (The has component of that automaton is now used to decide what may be delivered 
to the client, as well as what may be revealed.) Also, the correctness guarantees are weaker — 
for instance, repeated deliveries of the same message, and deliveries to the wrong recipient, 
are allowed. A more complicated key distribution service specification will also be needed, 
including key requests and granting of multiple keys. 

The work of this paper has not addressed liveness properties. For the simple case of 
this paper, with a passive eavesdropper, liveness claims are certainly possible. They can be 
incorporated easily into the model in the form of time bounds, and proved using the usual 
assertional methods for timing analysis, such as those appearing in [5, 22]. For more active 
adversaries, more sophisticated algorithms can guarantee liveness properties, which could 
also be formulated as time bounds and proved similarly. 

Another interesting research direction is the modular introduction of probabilistic con- 
siderations. A great deal of reasoning about security protocols can be carried out in a 
framework in which it is assumed that certain low probability "bad" events simply do not 
occur. Such events might then be introduced separately, and general theorems used to limit 
their impact on system behavior. Such general theorems remain to be developed. 
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